The Utilities Experience

home *** CD-ROM | disk | FTP | other *** search

/ The Utilities Experience / The Utilities Experience - Volume 1.iso / software / text_files / misc / texturemap.txt < prev next >

Wrap

Text File | 1978-06-29 | 49KB | 1,097 lines

Amiga Texturemapped Games FAQ V 0.25 Table of contents I. Introduction 1. What is Texturemapping ? 2. What are the problems of Texturemapping on the Amiga ? 3. How can they be solved ? II. Short reviews of all demos/games known to me 1. Demos 2. Game-Demos 3. Games III. Rumours and other infos department IV. Doing texturemapping with emulators 1. Hardware-Emulators 2. Software-Emulators V. Algorithms 1. Terence Russells algorithms used in Wolf3D-2.lha VI. The Amiga Texturemapping online conference 1. The invitation 2. Some hints for people who do not use IRC often VII. What can YOU do to support this FAQ ? I. Introduction 1. What is Texturemapping ? Texturemapping is a method of wrapping bitmapgraphics around vectors or 3D based graphics in common. For games, texturemapping is mostly used doing very realistic Dungeons. In contrary to a dungeon like in Dungeonmaster or Eye of the Beholder, the player is not limited to some few directions, but he can turn around in TRUE 360 degrees, like in real life. Often the graphics is more realistic than the graphics of such block graphics games and especially the opponents of the player are done very well (using texturemapping and vector graphics ...) Texturemapping is used for role playing games and for dungeon action games (some of them able to handle more than one player at the same time). The most famous such games are Castle Wolfenstein and DOOM. Castle Wolfenstein is for PC and Mac, DOOM is for PC (and soon for Mac too). There are probably more texturemapping action games than texturemapping role playing games. The original creators of DOOM did no port to the Amiga and won't do so in the future. All the talk about "Amiga DOOM" is to do a similar game on Amiga, not the original DOOM. Most people speak of "Wolfenstein style" and "DOOM style" graphics engines to describe how GOOD the used texturemapping in a game is. DOOM engines are superior to Wolfenstein engines. 2. What are the problems of Texturemapping on the Amiga ? Texturemapping needs to put single pixels to a screen, not only LINES like in vector graphics. So you need both a fast CPU and a fast graphics for doing texture mapping. On PC (and on Mac) the color of each pixel is described by ONE BYTE... this is the so-called CHUNKY PIXEL MODE. On Amiga, the color of each pixel is described by EIGHT BYTES (for 256 colors). This is the so-called BITPLANE GRAPHICS. Easy to understand, Chunky pixel is better for texturemapping than bitplane graphics, as bitplane graphics only has 12.5% of the speed of chunky graphics. Of course, if you take less thean 256 colors the speed is better, and i was told, in this way you even may get a better speed than doing chunky graphics. Second thing, even if the 68040 is very fast, not everybody has got such a thing(i have :)))) ). But on PC most gamers have got a 80486 (Which probably is slower than the '040, but much faster than the '020). It is probably not possible doing texturemapping with an 68000. In addition, texturemapping should have 64 colors AT LEAST (maybe extra halfbrite on ECS ...) Third, a lot of companies let the Amiga alone (Boooooh... :((( ), and in special they did not want to risk coding something DIFFICULT on Amiga. And some coders simply are moronic DOS-lovers (greetings to ID Software (they did DOOM) and to Richard Garriot of Origin at this place... i hope they $"&$/&$"/$"/& (censored) !!!) 3. How can they be solved ? A) Copper Chunky Modes I told you before, that the Amiga is not capable of doing chunky modes. That is not 100% the truth. There is a type of copper cheat (the copper is one of the Amiga's graphics coprocessors), that in fact DOES chunky modes. The problem with this graphics mode is, it can only handle a resolution about 100x100 to 130x120 pixels (i do not know exactly, as i am no specialist in coding texturemapping ...) Compared to PC Games with 320x200 texturemapping this may look ugly ... (but it should be mentioned, games on PCs (at least on PCs that are not these absolute high-powered ones...) often do not use full screen graphics, and so often too use such resolutions. Copper chunky can't do 1x1 or 2x1 pixel resolution or something like that (i do not know exactly what are the limits for that Copper tricks... maybe an expert inc coding such things could tell me ?) B) Chunky to Planar Conversion Routines A Chunky to Planar Conversion Routine is a part of a texturemapping code, that takes graphics in chunky (one Byte per pixel) as input, and puts it as Bitplane Graphics on the Screen. Of course, this method needs much CPU-power. For most demos/games, you should have at least a '030 to get it smooth... and a lot of demos using this technique do not have FULL texturemapping... that is, they for example have no stairs, and everything on screen is on the same height level. Copper Chunky does this better, but has a low resolution... of course a '040 with a Conversion Routine can do fine things... C) Using a graphics board Graphics boards for the Amiga do not use Bitplane graphics, but, in fact, Chunky graphics. The problem is, not many people have such boards in their systems, in difference to the PC, where all graphics is based on such boards. But some coders said, they maybe will do an additional "graphics board version", that features the fast graphics chips with their chunky graphics... there is even a texturemapping demo running on EGS (EGS is a standard for Amiga graphics boards). D) Demo-Groups do the Games As those people who can do texturemapping best (on PC) often are DOS-lovers, on Amiga a lot of people of the demo-scene and others, who are not employed at software firms, began to code... and as software firms want to SELL, they will probably sell the finished products, even if they are Amiga-only... And of course there are firms DEDICATED to the Amiga, like Team17 ... they are in this texturemapping business, too ... II. Short reviews of all demos/games known to me The short reviews are done in a specific format, mentioning Name, Author Name (or name of one of the authors), Minimum System, Recommended System, Engine style, How smooth the scrolling is and how good the pixelresolution is. Then they are followed by a short description of the demo (of course i could say more of the most, but there are a lot of demos reviewed...) Then i list the E-Mail of the author (if available) and where on Aminet sites to find the demo (if possible). I recommend using ftp.uni-paderborn.de or src.doc.ic.ac.uk or another site with complete Aminet. Some smaller sites only have got the latest uploads to Aminet. Wuarchive is a good choice, too. And there is another good site called ftp.netnet.com or something like that. You could look at ftp.luth.se, too. Used abbreviations : Minimum/Recommended System All = All Amigas with 1 MB chip at least 020 = All Amigas with 68020 at least AGA = All Amigas with AGA 030 = All Amigas with '030 at least 040 = All Amigas with '040 at least 060 = All Amigas with '060 at least (Joke! :))) ) FPU = All Amigas with FPU at least EGS = All Amigas with EGS graphics boards Engine style Low = Engine worse than Wolfenstein, Wolf = Wolfenstein-style engine :) = A little Better than Wolfenstein, worse than DOOM :):) = MUCH better than :), but not DOOM ... DOOM = DOOM-style engine Bey = Engine BEYOND DOOM Smoothness VSm = Graphics very Smooth Smo = Graphics smooth NSm = Graphics nearly smooth Not = Not very smooth graphics Pixel resolution Cop = Probably copper chunky or some other copper cheat, maybe i am wrong. In special CopL says low pixel resolution, CopM medium and CopH says high resolution (but i think it is impossible of doing a copper display with a pixel resolution you could call HIGH). CopM probably is worse than Med. I used the CopL-CopM abbreviations only to have SOME METHOD to differentiate between different kinds of copper displays. Low = Low resolution (probably something around 2x2 or worse...) Med = Medium resolution (probably something around 2x1 or 1x2 ...) High = High resolution (probably 1x1 ...) Coded by (P) = Single Person (G) = Demo group (PO) = listed person is one of those doing the thing... but there are others... (SF) = Software firm All speed remarks are relative to my own system (hehehe...), an A4000/040 with 14 MB RAM and a Piccolo SD64 graphics board (not the standard Amiga, isn't it ?) If you have an Amiga 1200 without accelator and did some tests you may wish to mail your results to me ... I have to remark too, that the comments are NOT objective... i like some demos and games, and do not like others... no one should take it as an insult, if i give his favourite demo a bad mark... it is only a try done by me... if you think the other way round, tell me... maybe you can convince me to change the FAQ as to one specific demo :))) I chose to be STRICT in the remarks i had to do ... in order to show the differences between the tested engines ... but of course i know how much work it is even to do a texturemapping demo in LOW resolution with a TM-Engine that suxx... Sometimes i wrote something like Low/Wolf... then i did not want to say Low, and not Wolf... again... everything very subjective ... Ah... about that "recommended system" things... Just guesses... Nearly all of the demos are on Aminet and for most of the demos you will find in the FAQ in which directory. Most of the demos also are (for the Germans reading this FAQ) available on the Birdland BBS (number found at the end of this FAQ). 1. Demos Only Demos with texturemapping parts that could be used in games are mentioned... no textured spheres, cubes and such things... all things mentioned in the chapter "Demos" will probably never get games ... ************************************************************************ Mindflow Stellar (G) AGA (4 MB RAM) AGA (4 MB RAM) :) NSmo Med One of the effects of this demo is a dungeon that looks nearly like the dungeons of the game Ambermoon. The textures of the ceiling and floor are MUCH better than in Ambermoon, but Ambermoon is smoother ... Author : Stellar (One email of a Stellar-Member is jsaarinen@kone.fipnet.fi, this is Nose/Stellar) File : /pub/aminet/demo/aga/mindflow.lha ************************************************************************ Motion Bomb (G) AGA AGA DOOM Not/NSm Med One of the effects of this demo is a FULL texturemapped DOOM engine with stairs and all. Bravo, Bomb !!! You should do a game out of this :))) This demo did not run on my A4000/040, but i did get a patch from some- one... i do not think this patch is on Aminet, though ... one last word to the engine... there are stairs and all included, but the Speed i think is not that sufficent for a game ... okay for a demo though... Author : Gengis/Bomb File : /pub/aminet/demo/par94/MotionDisk1.dms /pub/aminet/demo/par94/MotionDisk2.dms ************************************************************************ Doomed Pearl (G) All All Low VSm CopL A demo where you can use the joystick to wander around... but i decided not to do it to the Game-Demos, because the only intention to do this one was, to prove it is possible of getting 50 fps on a plain A500. Someone of Pearl tried to enhance the engine, but as this did not work, the demo died. Talking about resolutions, there are copper chunky demos with better resolution. Author : Netrunner/Pearl (9308938m@lux.levels.unisa.edu.au) File : /pub/aminet/demo/euro/Pearl.Doomed.lha ************************************************************************ Phobos Cydonia (G) All (???) All (???) Low Smo CopL One of the earlier approaches to Amiga texture mapping. It has no floor textures and turning around does not look like it SHOULD... but asides from that the speed is impressive. You can use your joystick to walk the dungeon, in contrary to most not-game demos. The resolution is weak. Author : ??? File : ??? ************************************************************************ Fullmoon Fairlight (G) AGA AGA Low NSm/Not Low Even if Fullmoon is a very nice demo, the texturemapping part is not very well done. The scrolling is not smooth, there are no floor and ceiling textures and the resolution is low. The not texturemapping related parts of the demo are nevertheless great ! Author : ??? File : ??? ************************************************************************* HOI-SAGAIII TEAM HOI (G) AGA AGA Low NSm/Smo Low The texturemapping part of the demo has no ceiling textures, and the floor textures are not very well done. The speed is better than that of most such "little hacks", but there are better texturemapping demos than this one. Aside from this flaw, HOI-SAGA III is (looked upen on it as demo in common) okay. Author : Teamhoi@SterrBBS.nl (or was it TeamHoi@SterBBS.nl ???) File : ??? ************************************************************************* 2. Game-Demos Game-Demos are Demos that are probably on their best way of getting games. Some of them actually will get Games, some not ... ************************************************************************* Warp_S O. Groth (PO) 020+HD AGA + Fast Ram :):) Smo/Vsm Low/Med Really a nice engine, the only DOOM style engine on Amiga with monsters running around. This one will be a game 100%. Playable demo will be out maybe February or March. The resolution and graphics are not the best at the moment, but the next Demo out will (according to the beta i saw) be much better. They got a new graphician, who is very good (i know this one :))) ). Maybe the most promising demo of them all. It will get a graphics board version, too, and an extra version that is '040-optimized (higher resolution !!!) was promised sometimes... Was in the beginning called Texmapp... The release version probably will be faster than the demo. Uses not only 90 degree walls. Decompresses monster GFX in real time. Author : O.Groth@link-M.muc.de File : ??? ************************************************************************* POOM Parallax (G) AGA 030+AGA :):) Smo High Maybe the most famous Amiga texturemapping demo. But it got very quiet around it since October '94. Maybe they dropped it? Or maybe they will bring out a complete game from one day to the other? There is a V0.3 on a finnish BBS ... the coders did some talk about a "maybe" graphics board version. POOM0.2 only has rectangular walls. The phone number of the Finnish BBS is +358 18 161 763. If you are from Finnland and want to be nice, maybe you could send me a copy ??? Per EMail, for example ??? POOM0.2 is on Aminet ... As to V0.3 Beta, it is much smoother, you can select a resolution from 32x32 up to 320x256 (the latter did not work on my system, though...), you see the gun and there are some new textures (a complete floor texture too...). As soon as you quit the Beta, it crashes. The Beta does not run with 2 MB. Someone said, the guys of Parallax would be working on something else at the moment, so the next release of POOM would be some time away. Author : ??? File : ??? ************************************************************************* BSP John Fehr (P) All 040 DOOM Not Low/Med This Demo reads an original DOOM-Wad-File and tries to interpret it. This is SLOW, because WAD-Files were made for the PC, not for the Amiga ... they are Intel-optimized... the WAD-interpreter BSP has no ceiling or floor, but many features (because of the WAD ...) As it is No-Aga and not very smooth, i do not think it is more interesting than for example POOM or Warp_S. But it was probably VERY MUCH work to make this thing reading .wad-Files ... and those multiple textures things probably cost a lot of speed too... there are AGA versions in the archive too... they too do not have floor and ceiling, but look better than the ECS-version ... I was told, it seems, John Fehr now is doing something further with his engine, but as to now i have no conformation from himself (so, what about, this, John, if you read this FAQ ? :) ) Author : fehr@rpm2.aes.mb.doe.ca File : /pub/aminet/gfx/misc/bsp1.0.lha ************************************************************************* Tmapdemo C. Green (P) AGA AGA ??? NSm High This demo comes with complete source... the author allowed doing a game with his routine (he probably won't do himself ...) The engine is quite cool, but very incomplete... just some blocks with Pics on the walls... no collision check... but a floor... Author : chrisg@commodore.COM (this email of course does not work ...) File : ??? (with source) ************************************************************************* Tmapdemo S. Boberg (P) EGS EGS + EGS board ??? VSmo High A Port of Chris Green's texturemapping engine to EGS... according to the author a quick hack... probably won't get any further... Author : ??? File : ??? ************************************************************************* Dentaku26 A.J.Amsel (PO) AGA/CD32 AGA/CD32 Wolf VSm CopL/CopM Dentaku will be a Wolfenstein/DOOM-style game (probably with level editor and serial device support). A.J.Amsel said to me, a demo will probably be released in April 1995. An older demo (executable from September) is available on ftp.luth.se. According to the mail information A.J.Amsel gave me, he and the others formed now a software company which is called Silltunna Software. They are two Coders (one of them A.J. Amsel), one artist and Alistair Brimble doing the sound. The game uses a copper display for its texture mapping routine. If you are a coder, an artist or a sound specialist, you may wish to contact Mr. Amsel. Maybe you could join them in there project (Mail to A.J.Amsel@exeter.ac.uk). A former Demo of Dentaku was DentAWolf, but it has not much to do with Dentaku as it is now. The ratings for DentAWolf are Low/Wolf,VSmo,Low. The version of Dentaku found at ftp.luth.se is only optimized for low end machines (but in my opinion it is good enough on high end machines... maybe there is even room for an improvement of the engine :))) And the engine does >20 fps on low end machines too...) Author : A.J.Amsel@exeter.ac.uk File : /pub/aminet/demo/aga/dentwolf.lha (DentAWolf...) ftp.luth.se/pub/aminet/demo/aga/dentects.lha (Sept. Executable of Dentaku26 ...) ************************************************************************* ChunkyMaze D. Bryson (P) AGA AGA Wolf VSmo Med A little dungeon with flickering torches and some pictures pinned to the wall. It has no floor or ceiling textures and in some distance the textures do not look nice. But there are worse tries. This project is (even if there are better approaches) still alive, but as David Bryson told me, the problem is the TIME. Anybody willing to help him, should contact him per email. He did not do anything further by himself, but Lee Metcalfe did some very nice graphics for the demo, and Paul Heams coded a little further. David would like it, if someone with LOTS of time picked this demo up. He would help this one with the source, of course. I found a very similar demo on my harddisk (even the same textures...) which is called wolf. I think it is an earlier or later version of ChunkyMaze, but i do not have the docs. Author : ceedb@cee.hw.ac.uk File : /pub/aminet/gfx/aga/maze.lha ************************************************************************* TextDemo5 J. Hendricks(P) 020 030 :) VSmo Med In Fullscreen probably the fastest engine on Amiga (okay, POOM has floor and ceiling textures and is not much slower...). Textdemo has Lightsources, not-rectangular walls and the resolution and screen size can be customized. The demo has OCS, ECS and AGA versions. It uses some very tricky Chunky2Planar code (using even the blitter...). There is a TextDemo6 in work, and as i was told this one will probably be one of the best texturemapping demos on Amiga. Author : john.hendrikx@grafix.xs4all.nl File : /pub/aminet/gfx/misc/TextDemo5.lha ************************************************************************* TextDemo6 J. Hendricks(P) ??? ??? ??? ??? ??? A long time, there was nothing new about Textdemo, but appearently, there will be a release this or next week. This release will be TextDemo5.7, which is near the features TextDemo6 will have. Since quite a time there are Beta Versions of this ones floating around (that is : to people that are working at the project with John) and i was told, the engine would be "virtually playable" on a 50 MHz '030 with 320x256 and 1x1 pixels. Some expected features : - Realtime movement - 128x128 textures (looks MUCH better according to John) - Multiple height walls :))) - Floor textures - "Bouncing movement" - Object-mapping-code for monsters included - Textures take 24 Bit as original (so port to graphics board version would be easy) I did not see TextDemo5.7 up to now, but this sounds WELL :))) Asides from Johns Mail i got info from Mike Bromery (davereed@wam.umd.edu), who told me, that John would have joined with David Bryson and he himself and Tomwoof would have joined too. Mike worked with Jason Freund before, and after Rot3D died, he tried to work with Jason Doig of Dogenstien3D. But it seems, Jason Doig lost his internet account, and so Mike got to John Hendricks. Mike said, there probably would come two projects out of this movement, but the next release still would be called TextDemo6. Release date of the demo will probably be the 12th or 13th February 1995. Author: John.Hendrikx@grafix.xs4all.nl File: Not yet available ************************************************************************* Reality AGA UWDesign(G) ??? ??? ??? ??? This project is at present a Wolfenstein type engine that has up to now not made it to a public release. I got some infos about it : - Aimed for A1200 and CD 32 - Static and moving objects - Solid and see through walls - Floor and ceiling textures (will be done later) - 1x1, 2x1, 1x2 and 2x2 pixel resolutions - walls at any angle and of any length - 64 colour GFX, maybe soon 128 or 256 colour GFX - external back drop pictures - simple multi height walls - graphics board version (will be done later) - ECS/OCS version (later, with some reduction) - 320x256 1x2 in 7-8 fps on A1200 with 4 MB Fast - 320x256 1x1 in 5-6 fps on A1200 with 4 MB Fast There will probably be a demo release in 2-3 weeks ... Author: ??? File : Not yet available ************************************************************************* Dogenstien3D J.D.Doig (P) AGA AGA Low/Wolf VSmo Low Texturemapping engine where you can see the gun while walking around. As to the graphics, most other engines are better. I don't think this one is still around. The first version was called Dog3D. Author : jasond@cee.hw.ac.uk (it seems, that this is no longer valid) File : /pub/aminet/gfx/misc (if it is still there ...) ************************************************************************* Wolf23_ish Chris Colman(P) AGA AGA Low VSmo Low A "first try" texturemapping demo. In the Readme the author writes he will make this one better. It is NO copper chunky. But "as is" it is not very good. An older version was wolf2.lha. Maybe another demo i found somewhere (but lost the readme...) is an older or newer version of this demo (it is quite similar). It is called wolf10. But maybe it is only a similar demo from another author. Author : cpc16@cus.cam.ac.uk (this account is no longer valid ...) File : /pub/aminet/gfx/misc/wolf3.lha (wolf10 is /pub/aminet/gfx/misc/wolf.lha) ************************************************************************* Wolf3D T. Russell (P) All All Low NSm Low Another "first try" demo. I do not know anything about what got with it after this release. Author : russell@cpsc.ucalgary.ca File : /pub/aminet/dev/src/Wolf3D-2.lha (with source) ************************************************************************* Rot3D J. Freund (PO) FPU+1.5 MB FPU+1.5 MB Wolf VSmo Med/High One of the first, if not THE first texturemapping engine on Amiga (now in its latest version). The wood textures of the demo look quite well, as do the stone textures, but there are no floor or ceiling textures and POOM, TextDemo5 and Warp_S are better. If no one picks this one up, it will die. The authors said they would help a potential "up-picker". Author : freund@cis.uab.edu File : ??? (Source also available on Aminet) ************************************************************************* 3. Games ************************************************************************* TrickOrTreat D. Stuart (P) All All Wolf Smo Low Little texturemapping game, where two players try to shoot each other. The graphics is not the best and there is no floor or ceiling texture, but it is the first texture mapping action game on Amiga (yes, it is this one, NOT Fears !!!) Even if the graphics is not comparable to Wolfenstein, the game is a lot of FUN. The author wrote he was looking for some work in coding the Amiga. Author : ??? File : Amiga User International 11/94 (Coverdisk 45) Or : Duncan Stuart,10, Bramble Close, The Beeches, Uppingham, Rutland, LE15 9PH ************************************************************************* Fears BOMB (G) AGA AGA Low/Wolf VSmo Low/Med This is a Wolfenstein clone for Amiga. The walls are better than nothing, the floor textures nearly nothing, the monsters do slide instead of walk, but it is a COMPLETE GAME. It is shareware. There is even sound while playing. And it is really FAST. Author : Gengis/Bomb File : ??? ************************************************************************* Ambermoon Thalion (SF) All 030 :) VSmo Med Ambermoon (do i have to explain this ?) is probably the best fantasy RPG on Amiga. Using a cool texturemapping routine. Okay, the monsters of Ultima Underworld on PC are better, but what do you want? This one is LoRes, 32 colors !!! One minute of silence for Thalion... may they rest in peace... OR be back and do something like that in AGA ??? :))) But sure, that won't happen... and the programmers for Ambermoon are now at Blue Byte, doing Ambermoon's sequel Albion for PC only... BLUE BYTE SUXXXXXXXXXXXXXXX!!! Ambermoon is a commercial game. ************************************************************************* Legend of valour ??? All ??? Wolf(???) ??? Low (???) Legend of Valour is a texturemapping fantasy RPG on Amiga. It is a commercial game. I do not own it and only saw it once, so i can't say much about this one. But it is not such BIG stuff like Ambermoon. ************************************************************************* A last remark for this chapter : The game DeathMask is no real texturemapping. It is a block graphics game which scrolls around while you turn 90 degrees. Better play Hired Guns ... ************************************************************************* III. Rumours and other infos department 1. Maybe DSA 2 (a texturemapping RPG with a really cool engine already released on PC) will come to the Amiga, maybe not. I heard rumours about a spring release (and my software dealer said there would be a good chance for this one to be ported). I do not know if it is AGA, but i think, if they do it, it will be AGA ... 2. Team 17 is currently doing Alien Breed 3D, a DOOM clone. They will use copper chunky (see above), and full texturemapping (stairs, different levels of sight and all ...) They even said something about cool water effects in the game. Since December they said they will release a demo soon... but as far as now, this demo is not released. 3. There are rumours about ACID Software doing a clone. 4. Some guy on the net wrote there would be a clone from some polnish scene member. He could not remember the name, though, and i do not know, if this guy is reliable. 5. According to Amiga Report 233, AGE Entertainment is working at a scrolling dungeon game. The game should come out as "Paranoia" and the project began quite a time ago. According to the article in the meanwhile the programmers think of the Amiga as a dead platform (the programmers of Paranoia, not AGE Entertainment !!!), and even if they wanted to finish the ECS version of the game, they wouldn't do the AGA version and the CD 32 version that were planned at the beginning. Nor would they do the planned sequels to the game. 6. Some time ago a group looked for coders for porting the game BOOM that they were doing for the Atari Falcon to the PC and Amiga. I do not know, if they found any Amiga programmers for doing the port. The game should be in three parts, and one of the three parts would be a DOOM style action game. I heard, it would be near finished (or finished...) for PC ... (EMail : rrfriede@cip.informatik.uni-erlangen.de) 7. In the latest add from my software dealer there were announced some games for Amiga AND PC that use texture mapping. These games are Body Count, The castle of Dr. Radiak and the sequel of Elder Scrolls, Daggerfall. I do not know, if this is an error or what (as i never heard anything about it before ... and usually such things do not go unnoticed...) And some of these releases were marked as CD and there was NOTHING written about CD 32 ... this looks strange... but maybe at least ONE is TRUE (if so, i hope it is Daggerfall :))) ). IV. Doing Texturemapping with Emulators 1. Hardware-Emulators Hardware-Emulators, that is ... putting INTEL-PROCESSORS in your poor little Amiga. You want to do THIS ? Oh, than you are running PC games, not Amiga ones... therefore i do not write ANYTHING about it in my FAQ. Because this is nearly no emulation anymore... it is ... gaming on PC ... there are quite well emulators of this style called "GoldenGate". 2. Software-Emulators There are some software PC emulators, but for games like DOOM they are not useful. They are slow and only emulate a 8088 or 80286. DOOM needs a 80386 AT LEAST to run. Maybe on PC Task 3.0 Wolfenstein will run. But the speed (espescially the speed of the graphics) surely is a problem. Maybe with a graphics board, but probably even this is too slow. So ... wait for PC Emplant's CPU transcription mode (this one will not be included in the first version of the emulation software, it will come as a free update later ...) Second ... Mac emulation with software... there are two emulators... AMaxIV and Emplant... as i heard AMaxIV does not run on AGA ... and it uses tricks to be able running with a 128KB ROM ... i doubt games running on this one, but maybe i am wrong... On Emplant (which i own myself) i tested four texturemapping games for Mac : The demoversions of these games (which i tried...) are on ftp.hawaii.edu in /pub/mac/info-mac/game/com. You will need StuffItExpander to decrunch them. Wolfenstein : Runs on my A4000/040 with reasonable speed (even if i do not use the graphics board ... with PAL Hires AGA ...), but only with the smallest screen. Not very well coded, as it is not very smooth on the graphics board either... (okay, with 320x256 it is something near smooth ...) Sensory Overload : Wolfenstein Clone, but i do not like the graphics... okay, the screen is bigger than most of these demos for Amiga... but the graphics is not much better... i think worse... Sensory Overload does not run well without a graphics board. Pathways into Darkness : Wolfenstein clone from Bungie (Bungie1@aol.com), i think the graphics is better than Wolfenstein, but Wolfenstein has a background music and PID don't ... it is slow, but in LoRes playable without graphics board... not much faster with graphics board, though ... Marathon : The absolute Mega-Game ... rating, if we do it as with the Amiga demos above : BEY !!! (Yes, this one is MUCH better than DOOM ...) If you are doing EVERYTHING to play DOOM on Amiga, take this one, take the smallest screen size, no music, select that the game only displays every second line... and run it on at least a 4000/030. But do not show it to your PC friends, they will LAUGH at you, if you do not own a graphics board... (i did, before i got mine :((( ) On a graphics board, Marathon is FANTASTIC, better speed than Amiga graphics demos, maybe even better than DOOM on PC (remember, Marathon is 640x480 ...) I use a resolution of probably 400x300 in Lores, and it is absolute smooth on the SD 64 ... Marathon is the sequel to Pathways into Darkness. One Last : It is rumoured, at 15th April, DOOM II will be released for Mac... 68040 and PowerMac, to be exact... V. Algorithms In this chapter i will put algorithms or coding hints sent to me. Please do not send code (this would be MUCH to specific for this FAQ). 1. Terence Russells algorithms used in Wolf3D-2.lha Basic structures and algorithms used to create the Amiga Wolf3D demo. The techniques I have used do not involve ray-casting for the rendering or BSP trees for hidden object removal. Instead my style of rendering has more in common with flat-shaded polygon rendering used in many older demos. Sorry for the crappy organization. I'm a fourth year computer science student and I haven't much time to do this properly. The Maze and basic objects: The maze is essentially two dimensional and if looked at from above it would appear to be a grid whose squares are outlined with walls or are bisected with doors. Each square from above is 64 x 64 pixels in dimension. I use pixels as a unit of measurement since in fact each point is represented by a pixel column in a bitmap. The use of the grid analogy is purely conceptual, however, since using a grid structure would create some complications (which are described under 'collision detection' and 'door movement'). For purposes of discussion I will refer to the X and Y axis' as being the east-west and north-south axis' (respectively) of the grid from an above view. The Z axis will refer to the axis that comes up out of the grid. (This runs contrary to how I actually programmed the demo as the Y and Z axis are swapped). Walls and doors are represented by the same basic unit: the block. A 'block' is from a structural standpoint the canvas onto which wall and door imagery is 'painted' or 'mapped'. Every wall and every door in the maze is associated with a block. In fact a block may consist of up to 4 walls that represent the 'north', 'west', 'south', and 'east' faces of the block. From a programming view a block consists of 256 points plus a center point. The center point positions the block relative to the bottom-left corner (0,0,0) of the maze. The remaining 256 are divided into 4 groups of 64 points, each of which are associated with a particular block face. All 256 points are relative to the block's center point. (Hence, only one set of these points need be maintained for all blocks within a maze). As can be imagined the end-points for each face overlap. The walls points are given the following offset ranges: SOUTH: (-32,-32,0) to (31,-32,0) NORTH: (31,31,0) to (-32,31,0) EAST: (31,-32,0) to (31,31,0) WEST: (-32,31,0) to (-32,-32,0) Notice that for each face the ranges are given in an order which implies counter-clockwise as viewed from above the grid. This is important for properly rendering the wall graphics and for backface culling, that is, removing walls that are facing away from the observer/player. Each wall/door has an associated 64 x 64 pixel bitmap. Each 1 pixel wide column of the bitmap is represented by one of the points found along the wall/block face. Hence point 0 of the south wall of a block may represent the 0th column of a 'stone wall' bitmap. From the programmer's view I use the wall point's ordinal value (it's relative position) to offset/index into the bitmap image. Previously I mentioned that blocks are used for BOTH walls and doors. The attentive reader may have noticed that the offsets for the walls would create doors that are not located in the center of a block. Since my aim was to create a near Id wolf-clone I had to specify extra offsets just for the doors. These new offsets simply have either the X or Y component zeroed depending on which direction the door is to lie along. This allows the doors to appear in the center of a block. This also makes it easy to have sliding doors since all I really need to do is move the associated block's center point in the direction the door opens. The door then slides 'into' an adjacent wall block which takes care of hiding the door. (This is explained later in the next section). RENDERING - this is just a quick and dirty algorithm Translate the block centers by an amount equal to the players relative maze position. Now rotate these centers using the players attitude or angle of direction, also relative to the 0,0,0 point of the maze. Next rotate the 256 wall points using the same players direction angle. For each block center, translate a copy of the 256 wall points to the block center such that the block center is in the middle of the points. Now that we have a list of block points that are relative to the player's position we want to render the blocks. To determine what blocks are visible I simply sort them by there Y value, (which is now relative to the player's position). I used this method since at the time I did not know of the BSP tree method for determining visible polygons. Once we have a list of sorted blocks, we can immediately discard the blocks that fall behind the viewer. From this point we render each block until the player's view is completely filled with graphics. Since I don't want to draw all of the blocks that are in front of the user, (just the ones that fill up the view), I use a pre-render loop which determines what portions of walls/doors are visible. To determine what is visible I use the sorted list of blocks and an array called the xBuffer. This buffer is one dimensional and has an entry for every vertical column of the user's game display. The algorithm involves a lot of simple parts that when put together create a fairly complex program. Hence I will attempt explain it using two similar explanations. EXPLANATION 1: I use the following algorithm: clear the xBuffer while xBuffer is not full do get the block closest to the player for each face of the current block do if current face is invisible then skip face else "current face is visible" for each of the current face's 64 points do perform a perspective calculation on the point to get a screen X1,Y1 point. duplicate X1 into X2 mirror Y1 across the center of the display to get Y2 the line (X1,Y1)-(X2,Y2) forms a column of screen points onto which a column slice of the wall/door bitmap will be mapped/scaled. if X1 lies with in the range of the xBuffer (usually 0-319 for a full screen) then check xBuffer[X1].height to see if a column hasn't already been written there. IF height of current line > xBuffer[X1].height THEN xBuffer[X1] = current column and it's associated bitmap imagery. else discard this column as being invisible. endif "If all I did was insert just the columns into the xBuffer there would be gaps in-between the columns do to the perspective transformation, hence I need a little loop that makes a copy of the current column back to the previous column of the same wall." end-if end-for end-while For example suppose my maze viewing area is 320 pixels across the screen. Then the xBuffer has 320 elements. Each element is a structure that records: the half-height of the wall/door from the horizon or the equator of the viewing area; the bitmap identifier; the pixel column offset into the bitmap Now using the xBuffer I have a routine take each element and read a column of pixels from a bitmap and then stretch and clip the bitmap into the hidden rendering buffer. EXPLANATION 2: while not done do check closest wall/door's extents (i.e. the starting and ending X locations as project on the view) if the extents are outside the viewing area then discard the wall/door else for each of the 64 points/columns of the wall/door determine where the column is relative to the view area if the column lies in the view area then check the corresponding xBuffer element to see if something hasn't already been written there if empty then write the columns height and bitmap column offset and bitmap identifier to the xBuffer. else if current column's height is greater then write it else this part of the wall lies behind some other wall end end end end end end Starting with the closest block I check each face to determine if it is visible. Since the faces of the blocks are at angles of 90 and 180 degrees from each other, at most 2 faces will be visible at any one time. Once I determine a visible face I use the associated 64 points for that face to determine visible columns. To each point I add to the Z component an amount equal to have the height of a wall. Then I run the point through a simple perspective calculation and I now have a somewhat correct position for projecting the point onto the player's view. I next create a duplicate of the point and mirror it across the middle of the player's view. This gives me two points that represent a line or column of the wall's bitmap. Since each point of a face is uniquely associated with a column of pixels in a wall bitmap I can perform some sort of 'texture' mapping now. Only one thing remains, and that is to determine the next columns position. Since as you get closer to a wall the 64 points will be spread out over a greater viewing area, gaps will start to appear between the columns. These gaps are eliminated by copying a column up to the next column. Collision Detection: Some authors have suggested using a static grid to perform collision detection with walls. Generally this works very nicely, however, in the case of Id's Wolf3D there is a slight problem. Id's game supports moving walls (in other words the secret passage-ways). To perform collision detection on these moving walls while using the static grid meant that I would need to either create special case for checking when a wall was moving, or would have to create a special kind of block: i.e. a moving wall block. At the time I decided this was unsatisfactory so instead of using a grid I decided to use the block's center point and a bounding box around the player. Using this method, collision detection involves checking each block center to see if it lies within the players bounding box. This allows me to move blocks at will without worrying about special cases and is generally pretty quick. There are many more points to the algorithms I have used, and if you are interested in understanding them and want to learn a maze rendering technique that does not involves ray-casting then send some email. Terence Russell russell@cpsc.ucalgary.ca VI. The Amiga Texturemapping online conference 1. The invitation At 7th February (Tuesday) at 22.00 MESZ (16.00 EST or 15.00 Central US Daylight Saving Time) there will be a online conference on IRC about Amiga Texturemapping. The conference will be on a channel name #amitmap. Everyone who is interested in Amiga Texturemapping is invited. The talk will be about the future of Amiga Texturemapping and as some programmers already announced they would be there probably some coding themes. Maybe there will be the possibility to find more people for an own project. 2. Some hints for people who do not use IRC often IRC is the online chat system of the internet. Try out the command irc on your site. If this does not work, contact your system administrator and try to convince him to install an irc server :))). As you entered irc, you specify your nick name (the name under which you will be known), with /nick Nick-Name. An alternative is starting irc with irc Nick-Name. To enter a channel (a channel is a place for people discussing a specific theme to meet), you type /join channelname. Each channelname starts with a #. To send someone a private message (that other can't read) you type /msg Nick-Name "...", where Nick-Name is the Nick-Name of the user, to whom you will send the message. To send a message to all users in this channel, simply type what you want to say. Usually you should write it in the following way : Name of the user for whom this message is primarily : Text. /who * lists all users currently on this channel. /list * counts the users on this channel. With /quit you quit irc. That are only the basics for irc, but with that knowledge you can be with us at the conference :))). Irc also has a help-system installed, by the way. VII. What can YOU do to support this FAQ ? 1. Support Amiga 2. Write texturemapping demos/games on Amiga :))) 3. Buy Amiga texturemapping games, if they come to a release 4. If you know of any texturemapping game/demo not mentioned in this FAQ (dungeon-related, no texturemapped cubes and spheres), or if you have information relevant for me, mail to - haeuser@minnie.informatik.uni-stuttgart.de OR - call Germany 07021/861920 or 862428 or 862429 (Birdland BBS, i am Magic SN on this BBS ...) OR - Phone Germany 07021/51787 and ask for Steffen OR - go in irc and look for MagicSN (that's me :))) ) OR - write a letter to Steffen P. Haeuser, Limburgstr.127, 73265 Dettingen/Teck,Germany OR - Do whatever you want ... :) 5. Do the same, if you want to send me critics or beta-releases of demos to test them :)))))))))))))))) (at least i tried it... maybe someone would be in FACT that nice :))) ) My internet-account is able to handle BIG UUEncoded mail... :)))))))) 6. Spread this FAQ on all nets and BBS's. 7. If you are a coder, and you have a lack of time to code, or you have a serious problem in coding texture mapping, maybe you find some interesting EMail-Adresses all over this FAQ ... 8. Send me texturemapping algorithms you see no need anymore in keeping them private (for this new chapter V) That's it... as soon, as i hear news about some of the mentioned demos (or of some new ones ...) i will do a later version of this FAQ. It will be found in comp.sys.amiga.games at least... maybe soon there will be a later version of Warp_S or POOM or TextDemo or DentAWolf or... or ... ciao, Steffen Haeuser OR MagicSN (in irc) OR haeuser@tick.informatik.uni-stuttgart.de (E-Mail, talk ...)